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A METHOD AND SYSTEM FOR EXECUTING SOFTWARE ON NON-NATIVE 

PLATFORMS 



5 Field of Invention 



10 



The present invention relates to a method and system for execute software on non- 
native platforms. More particularly, but not exclusively, the present invention relates to 
a method for debugging a program on a non-native platform. 

Background 



Often there is a need to migrate software from one platform to another. To operate on 
the new platform the software is usually run within a software emulator which emulates 
15 the onginal platform. 

Generally, software emulators are supposed to be used only during the initial phase of 
migration when application deployment (on the new ptatform) is of utmost importance. 
But in reality, software emulators continue to be used for longer times due to various 

20 reasons, such as, a native port of the application being impossible due to toss of 
source code or being irrvractical due to cost. Hence there is a need for software 
emulators to be capable of emulating all the tools thai are needed to maintain an 
application on the new platform. One such tool is the debugger. In current 
implementations of emulators, support for debugger emulation is absent thus 

25 restricting the utility of software emulators for migration in situations where the emulator 
is going to be used for the lifetime of migrated applications. 

In addition, running the debugger fhOT tt* host platlomi to deb^ 
migrated to a new platfonn is impractical tor the following reasons. 

30 

(a) The debugger which the user is accustomed to rnay not be capable of 
performing across-network debugging. 

(b) A debugger user may have certain debugging scripts or other methods which 
35 may have to be modified when the application is rot local to the debugger. 
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Both of the above' issues defeat the purpose of software emulators, which is to 
minimise the migration-related changes that the user has to undergo. 

It is an object of the present invention to provide a method and system which meets the 
5 above needs and avoids the above disadvantages, or to at least provide the public with 
a useful choice. 

Summary of the Invention 

1 0 According to a first aspect of the invention there is provided a method of executing 
programs on a non-native platform, including the step of 

i) executing a plurality of programs in two or mors software emulators; 
wherein during the execution of the programs at least one program monitors or 
controls at least one other program's threads or processes using an interface. 

15 

Preferably, each software emulator emulates one program and is emulating the same 
platform. It is further preferred that an the software emulators are executing on a single 
computer system. The computer system may be UNIX-based The software emulator 
may be a dynamic translation software emulator such as Aries. 

20 

Preferably the Interface provides communication between the software emulator of the 
controlling/monitoring program and the controlled/monitored program. 

The controlling/monitoring program may be a debugger such as gdb-based debugger. 
25 In such as a case the controlled/rtwutored program may be a program that is to be 
debugged. Alternatively, the cortrolfeng/monitoring program may be any other type of 
tracing program such as truss on UNIX or tusc on HP-UX. 

The interface may include three components -a first modute for interfacing with the 
30 software emulator of the controlling program, a second modute for interfacing with the 
software emulator of the controlled program, and a framework through which the first 
and second module can communicate. 

It is preferred that the framework is an inter-process data exchange mechanism. The 
35 mechanism may be an interprocess communication primitive such as a pipe, a socket, 
or a shared memory ansa. 
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The interface may provide an additional system to enable the software emulators to 
communicate with each other over a network. 

5 The second module may include a thread which polls for requests received through the 
framework and services the requests when they are received. 

The controlling program may generate system calls which may be intercepted by the 
software emulator and processed by the first module. The system calls may be trace or 
1 0 trace-wait system calls. 

According to a further aspect of the invention there is provided a system for executing 
programs on a non-native platform including: 

i) a first software emulator adapted to execute a first program, to intercept 
15 calls from the first program to monitor or control the processes or 

threads of a second program, and to transmit the calls to an interface 
system; 

ii) a second software emulator adapted to execute the second program, to 
receive the calls from the interface system, and to effect the calls on the 

20 processes or threads of the second program; and 

ill) an interface system adapted to receive the calls from the first software 
emulator and to transmit the cafls to the second software emulator. 

According to a further aspect of the invention there is provided a method of debugging 
25 a program on a non-native platform, including the steps of: 

i) executing a debugging program on a first software emulator; 

ii) executing the program on a second software emulator; 

iii) the debugging program making calls to trace into the processes or 
threads of the program; and 

30 iv) transmitting the calls using an interface from the first software emulator 

to the second software emulator. 

Brief Description of the Drawings 

35 Embodiments of the invention will now be described, by way of example only, with 
reference t the accompanying drawings in which: 
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Figure 1 : shows a btock diagram of a possible application of the invention. 

Figure 2: shows a diagram illustrating a typical debugging process on a native 

5 platform. 

Figure 3: shows a block diagram of a system implementing the Invention. 

Figure 4: shows a diagram illustrating a debugging process on a non-native 

1 o platform using a method of the invention. 

Figure 5: shows a diagram illustrating how the invention may be deployed. 
Detailed Description of the Preferred Embodiments 



15 



20 



The present invention relates to a method and system for executing programs on non- 
native platforms when one of the programs must monitor/control the threads/processes 
of another. 

The invention has particular application as a mechanism to perform cross-platform 
debugging of software programs during their migration from one platform (host) to 
another (target). 



Referring to Figure 1, software 1 on the host platform 2 has been migrated in step 3 to 
25 a target platform 4. The software includes a debugger 5 and a program 6. The host 
platform program is run on the target platform and is being debugged on the target 
platform itself with the help of the host platform's debugger. 

The program 6 and the debugger 5 are executed within two instances 7 and 8 of a 
30 software emulator, and an interface 9 between the two instances is provided to enable 
the debugger to trace into the threads/processes of the program. 

In this example, the program and the debugger are native to the host platform and are 
executed on the non-native target platform. It will be appreciated that the debugger and 
35 program may not be executing on the same target platform and that the interface may 
provide a method for the debugger and program to interlace over a network. For 
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example, the program may be executed on a software emulator on machine 1 of the 
target platform and the debugger may be executed on a software emulator on machine 
2 of the target platform. 

5 The interface will be termed a Trac*£all Emulation Engine" (TCE). which, when 
augmented to a software emulator, makes cross-platform debugging possible. The 
Trace-Call Emulation Engine and the software emulator together enable the host 
platform's debugger to: 

(a) run on the target platform; and 
1 o (b) control the execution of another host platform software running on the target 
platform via the second instance of the software emulator. 

It will be appreciated that the invention may have application for any scenario where a 
program (controlling program) needs to monitor/control another program (controlled 
15 program) on a non-native platform. For example, the controlling program might be one 
used for tracing into another program such as truss on Solaris UNIX or fuse on HP-UX 

In this example the debugger Is the controlling program and the program is the 
controlled program. 

20 

The method of the invention is preferably implemented on a system which supports 
trace and trace-wait system calls. 

Trace car? 

25 

The trace call provides a means by which a process can control the execution of 
another process. Its primary use is for the implementation of breakpoint and event 
driven debugging. The trace can functions for both single and multithreaded traced 
processes. The traced process behaves normally until one of its threads encounters 
30 an exception (signal on Unix OS), or an event at which time the thread enters a 

stopped state (effected by the OS) and the tracing process is notified via frace-wa* call. 

A tracing process (debugger) can set event flags in the context of a traced process, or 
its individual threads, to cause the threads to respond to specific events during their 
35 execution. When an event-flag is set in the context of the process, all threads in the 
process respond to the event. When set in the context of a thread, only the specific 



21-08-2003 13:35 



64 4 4736712 



97X 



P. 06 



22. hi. 2003 0:31 BSW WGTN 64 4 47367J2 



No- 2506 P- 7 



6 HP 200208617 

thread will respond t the vent. A trace call can be directed either at the whole 
process or at a specific thread in the process. 

Trace-waft call 

5 

The trace-wait call provides a means to wait for a trace-event to occur. A tracing 
process (debugger) will normally invoke trace-wait after the traced process or any of its 
threads has been set running. Trace-wait synchronizes tracing requests directed at 
threads within the traced process. The debugger can wait for process-wide events 
10 and/or thread-specific events. The trace-wait call can be performed either in a blocking 
mode or a non-blocking mode. 

Typical debugging process on a native platform 

1 5 With reference to Figure 2, a typical debugging process involving a debugger and a 
program executing on a native platform wtil be described. 

A user starts the debugger and passes the name of the program to debug to it In this 
example the debugger relies on TT_EVT_£XBC event from the OS in order to set up 
20 the debugging. 

A means of communication (FLAG) is established by the parent and child processes 
before arriving at steps 10 and 1 1 . In step 10, the parent debugger waits until the child 
debugger says that it has now permitted itself to be traced by the parent, with the help 
25 of the OS. 

In step 1 1 . the child debugger makes a trace call 22 in the OS with TT_PROC_SETTRC 
request. The OS, from then on wiH mark this process as a "traced" process and will 
favourably process future trace and trace-wait cafe made by the debugger with this 
30 child process as the target Steps 10 and 11 may occur concurrently. 

In step 12, the child process has successful performed the trace call and 
communicates the same to the parent debugger via FLAG. 

35 in step 13. the debugger now makes a trace call 23 to set an event-mask on the child 
process. This event mask will inform the OS as to which event the OS should consider 

P 07 
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for reporting to the debugger. In the current example, the debugger requests that if a 
Tr_EVT__EX£C event occurs in the child process it is reported. 

in step 14, the child process waits until the debugger has finished step 13. 

5 

In step 15, the debugger asks the child process to go ahead with exeding the program 
via FLAG. 

After the debugger has finished with step 1 5, it goes on to wait in step 1 6 for the child 
1 0 process to encounter 1TJE VTJsXEC. To do this it makes a trace- wart call 24 in the 
OS. in blocking mode, this means that OS should stop the debugger itself until the 
child process hits upon at least one event in the event-mask as set by the debugger for 
that child process. 

1$ In step 1 7, whilst the debugger is blocking in trace-wait call, the child process goes on 
to exec the program. The OS will retain the event-mask and the SETTRC status that 
was set for the child process, for the new process program also. 

In step 18, the OS recognizes that the child process has hit upon the event 
20 TTJBVTJsXIsC which is demanded by the debugger earlier to be reported to it via the 
trace-wait call. Therefore, the OS first stops the child process at step 25 and sets up 
the concerned event. 

in step 1 9, as soon as the child process performs step 17, the OS will remove the 
25 debugger from the blocking state within trace-wait caH, and return the TTJBVTJEXEC 
event data to it. This data comai ns ail the Information about the child process at that 
stage of this execution. 

Before entering step 20, the debugger has obtained the event data from the OS and 
30 has come out of the blocking trace-wait call. From now on the child process is 

completely under the control of the debugger, in step 20, the debugger performs a 
trace call and requests the OS to continue the child process. 

In step 21 , the OS continues the child process. Now the exec happens and the child 
35 process becomes program. This program is subject to the same event mask that was 
set by the debugger on the child process in step 13 above. 
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From now on the debugger can perform various trace calls on program, wh/fe waiting in 
between for the program to stop at events, via trace-wit calls. 

5 A systtm for implementing tfre /nvwrtfon 

A system for implementing the invention will now be described in detail with reference 
to Figure 3. 

10 The debugger 30 and the program 31 are executed on the target pfatform within two 
instances 32 and 33 of a software emulator. 

An interface 34, TCE, Is provided to enable the two instances of the software emulator 
to communicate. 

15 

The interface includes: 

a) A module (TCED) 35 which is responsible for processing frece and frace-watf 
cafe 38 made by the debugger. 

20 

b) A module (TCEP) 37 which is responsible for servicing the requests passed to it 
by TCED. 

c) A framework (TCE Framework) 38 which enables TCED 35 and TCEP 37 to 
25 communicate with one another. The framework 38 comprises TFWD 39 (for 

transferring information to/from TCED) and TFWP 40 (for transferring 
information to/from TCEP) which together form an Mar-process data exchange 
mechanism. 

30 The software emulator 

A software emulator is a program that automatically runs an application belonging to 
one platform (host) on another platform (target). 

35 In this implementation the software emulator is a "dynamic translation'-based software 
emulator, ft will be appreciated that other types of software emulators may be used. 
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A dynamic translation software emulator uses a method of accelerating emulation by 
converting code sequences from the non-native software to code sequences which will 
run on the native architecture, on the fly. After a code sequence has been translated, 
5 the next time the execution path reaches that point, the translated code is run, rather 
than interpreting it. 

An example of a dynamic translation software emulator is Aries which is an emulator 
that transparently runs all HP-UX/PA-RISC applications on HP-UX/IPF. 

10 

The preferred software emulator (DynT) has at least the following functionalities: 

1 . Whenever a software belonging to host platform is run on the target platform, 
it is automatically (or with user's help) emulated by the DynTle. a host platform 

1 5 software can run on the target platform only with the help of DynT. 

2. DynT intercepts each entry of the program Into OS mode and inform TC£ 
that such an entry is about to happen. 

20 3. DynT informs TCE about all the exceptions that the progrvm encounters. 

4. DynT maintains the following information about the program. 

/. Infomiation about each thread in the program Is globally maintained - 
called TMJd hereafter. (Thdjd contains, importantly, TMJdstato 

25 and ThdJd.tContexf) - Thdjd.stat* is the state of the thread {running, 

stopped, etc.) and 7J»tf_/d-fConl«rt isthe thread's run-time context; this 
consists of all the emulated host platform machine register state, 
instruction pointer/address, stack pointer, global data pointer, thread- 
specific event mask, etc. 

30 ii. The program's process-wide information - catted Pdata hereafter. It 

contains program-wide information such as program-wide event masks, 
signal-masks, etc. 

HI. Information about each exception, pending delivery, for either the 
process or a thread in the process, is maintained - called Slgjd 
35 hereaft r. The exception pending delivery to ANY thread in the process 
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is maintained in Afete.SfgLjd and those pending delivery to a specific 
thread are maintained in ThdJ&SigJd. 
fa The translated code Reacted somewhere, then the cache area's 
start address) - called Ccacfte hereafter - This is taken to be a process 
5 global. 

5. DynT checks ThdJdJvmakjarterjDneJnst flag before emulating each 
instruction, and if this (lag is set, reports the same to TCE 

10 6. Aft the three repositories of information in 4 above, wifl be accessible to TCE 

or reading and writing. DynT makes available to TCeall the mechanisms 
needed to read and write Ccscht. 

In this example, a first instance 32 DynT (01 J of the software ©mutator emulates the 
15 debugger and a second instance 33 DynT (D2) of the software emulator emulates the 
program. 

DynTlntercepts each traceoU and passes on the parameters to TCED and TCEPon 
the debugger and the program side respectively. DynT passes on the values returned 
20 by TCED or TCEP to the emulated debugger/program. 

The TCED Module 

TCED 35 is interfaced to the DynT 32 on the debugger tide and is invoked by the DynT 
25 (D1) 32 at start-up. The DynT 32 intercepts each tracefirace-wait call 36 made by the 
debugger 30 and passes en the parameters oftheceftto TCED 35 . TCED 35, in turn , 
afomfcaty processes the to^^ 

(a) by making a corresponding trace can in the OS; 

30 

(b) by completely emulating the trace request on its own; or 

(c) by communicating with TCEP37. via the TCE Framework 38, so that TCEP 
37 performs the task pertaining to that request and returns back the resurts via 

35 theTCEttaroewor*38. 
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Results of the calls 41 are transmitted by TCED 35 back to the OynT (D1) 32. 

The TCEP Module 

5 TCEP 37 is interfaced to the DynT (D2) 33 on the program side TCEP 37 is invoked by 
the DynT (D2) 33 and is essentially comprised of two components: 

(a) A special thread 42 called TDTH. The TDTH thread is created as part of the 
program. It is mainly responsible for polling for requests on the TCE Framework 

10 and servicing them when they arrive. 

(b) Event generation and reporting structures. 

As well as servicing the nquest passed to it by TCED via the TCE Framework, TCEP 
15 is also responsible for processing trace and trace-wart calls 43 made by the program. 
However, in this example the program doesn't make any trace/trace-wait calls, except 
for one occasion In the debugging initialkation stage when a trace call is made with the 
request as TT_PROC SETTRC 

20 Vie TCE Framework 

TFWD 39 and TFWP 40 together form an inter-process data exchange mechanism 38. 

In this example, the TCE Framework 38 is a shared memory area. However, tn a Unix- 
25 like environment TCE Framework may be any inter-process communication primitive 
such as a pipe, socket or shared memory area. A shared memory area is the preferred 
choice if the debugging is not across systems. 

A section of the TCE Framework Is provided below: 

30 

(tfwd.; req (TFWP.) \ 
(TFWD.) Stefan (TF WP.) 
(TFWD.) datel (TFWP.) 
(TFWD.) datel (TFWP.) 
fTFWbT) event (TFWP.) 
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• *req' - this field takes values corresponding to a request 

• "status" -this field can take one of the following values: 

1) REQ_READY 
5 2) RESPONSE_READY 

3) NO_REQ 

REQ_READY wiH be posted by TCED and RESPONSE.READY wHI be posted 
by TCEP. 

10 

• "datal* and *data2' - these two fieWs are used for communteatiiig data such as 
thread ids, addresses, offsets, event-masks. 

• "event" - this field is written to by TCEP. 

15 

A method for JmphmofMngth»invwrtk>ri 

A method for implementing the invention will now be described by way of example and 
with reference to Figure 4. 

20 

Initialisation of TCED/TFWD 

The user informs the DynT {D2) 32 at the time of starting the debugging session that a 
debugger needs to be emulated. DynT(D2) 32 will then invoke TCED 35 during startup 
25 for the first time and setup its own internal state so that each tractrtraco-wait call made 
by debugger s passed on to TCED 35. TCED 35 initializes TFWD as soon as it is 
invoked by DynT (01). 

TFWD fiekls are initialized thus by TCED: 
30 TFWD.status »NO_REQ 

TFWD.req 'NONE 
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Initialisation of TCEP/TFWP 

(a) When a program performs a trace call with the request as 

TTJ'ROCJSETTRC, DynT (02) 33 invokes TCEP 37. TCEP 37 will then 
perform the following tasks and return to DynT (D2) 33: 



i. Create TDTH 

il Setup TFWP and initialize the fields of TFWP as: 
TFWP.request unchanged. 
10 iii. Make a corresponding trace call in the OS 

(b) When a debugged program executes another program through the exec 
system call, then TCEP that is attached to the new program will create 
TDTH and attach itself to the existing TCE Framework, In this case the 
15 TFWP.status will not be set as in step (a) above. 



One way in which information about the on-going debugging session may 
be communicated across the exec system call is by the DynT (D2) inserting 
a special environment variable for the program being exec'etf so that the 
20 new DynT that automatically comes up, after exec system call succeeds, is 

able to recognize that it is emulating a debugged program and hence invoke 
TCEP appropriately. 



(c) When the debugged program forks, and the user intends to debug the new 
25 process in place of the first one, then TCEP 37 in the child program will 

create TDTH and attach to the existing TCE Framework Also, the parent 
debugged program will detach itself from the TCE Framework and the 
TDTH of the parent debugged program will be terminated. 



30 In the following example a program is debugged by a debugger on a non-native 
platform. 



A user starts a host-platform debugger, debugger, on the target platform using a 
software emulator and passes to it the name Of the host-platf rm program, program. 
35 The user informs the DynT (01) 32 that a debugging session is being initiated and the 
DynT (D1) 32 wiU perfbmi the initializations to create the TCED 35 and the TFWD. 
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A means of communication (FLAG) is established by the parent and child processes. 
The following steps are then performed: 

5 

In step 50, the parent debugger waits until the child debugger says that it has now 
permitted itself to be traced by the parent, with the help of the OS. 

In step 51. the child debugger makes a trace call 60 in the OS with TT_PROC_SErfRC 
10 request. This step may occur concurrently with step 50. This request will be intercepted 
by DynT (02) 33 and passed on to TCEP 37. TCEP 37 services the trace call as below: 



TRACE REQUEST 


TCED(c*V99) 


TCEP (effect) 


IT^PROCJSETTRC 


Noacbon 


1. Create TDTH 
Z SetupTFWP 

3. Make ftace-caff with request 

4. Return to DynT 



In step 52, the child process has successfully performed the trace call and 
1 5 communicates the same to the parent debugger, via FLAG. 

In step 53, the debugger now makes a trace call 61 to set an event-mask on the child 
process. The event mask will inform the TCED 35 as to which event the TCED 35 
should consider for reporting to the debugger. In the present example, the debugger 
20 requests that if a TT_EVT_EXEC occurs in the child process it is reported. This cat! will 
be passed on to TCED 35 by DynT (01) and the following actions are performed: 



TRACE REQUEST 


TCED(**U9*) 


TCEP(tfhvt) 


ri PROC S£TjvYeNT_M 




vme(TFWD.status<** 


ASK 


n^PROC.S£T.EVENT_MASK; 


REQJiEADY) «tonotNng>] 




TFWD total -<ovwt mask passed by 






fobugger>; 






TFWD. status=REQ_R£ADY; 


2. Set 




Z. Whte{TFWD.statvs-- 


PdatM.*v9nt_m3sk=TFWP.<Jata1 




RESPONSE J^EADY) «tonom*ng> 


3- Set 






TFWP,steft/s*RESPONS£_READY 
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TKAGE REQUEST 




TCEPpmct) 


• 


4. Set fM**+—nt_mm**<eveat 

mas* passed by debugger* 

3RetumtoDynT. 





In step 54. the child process waits until the deto^oerfinisbes with step 53. 



In step 55. the debugger asks the child process to go ahead with exec'mg the program 
5 via FLAG The program is the application that is passed by the user as a parameter to 
the debugger, intending to debug it. 

In step 56, the debuggerwaits for the chHd process to encounter TT_EVT_EX£C. To do 
this It mates a trace-wall caH 62 in btoddng mode This means that TCED 35 should 
10 stop the debugs itself untfl the (^process hits upon at ieast one event in the event- 
mask as set by the debu^er for that chiJd process. TCED 35 servjew this trace-watt 
caH thus: 



i i ■ ■ «i 1 1 f Ta ~ **• ** 

psoeHMpff can 


rCED(cmrm) 


rCEP (effect* 


tfeto-iwf wrth 
DtocJong allowed, until 
event 000*9. 


y Set TFWD.rwrTHACSJVAiT; 
TFVW.st*tus*H£Q_READY 

2. Whte(7T=VW)^tetuf-« 
zVENT_FOUND) OR 

<don<Mng> 

3. \f(TFWD>st*US~* 
EVENT/OUND) ^en return to 
OynT, TFWO.evenf 


[ WN* pFWD.sfe&w — REQ_READY) 
<donothincf>) 

2Foreach7Wjcldo 
begin 

begm 

Set 7FVVP.evenf=TWJtf.ev*iiC 
Set TFWP.sta^&GNTJWND 
return to Dynl 
end 
•nd 

Set TFW.sM»NOJVEHTJ : OUND 



15 In step 67. whflsttne debugger Isbtocking in iiace-w^ call, the <*W process goes on 
to exec the program. DynT (D2) win retain the event-mask and the SETTRC status that 
was set for the child process, for the new process program. Because of the child 
proces* exeding program ths following acfonB in step 63 take place: 
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Event description 
(Event nemo) 



Program converting rtterf to 
mother program 

(TT.EVTJXEC) 



Unix system ceil that FCS* actions 

mey teed to the event [entry into TCEP is when Dyn T reports the 
sorrespondiog system cal entry to ICEP) 



l.lrwens special environrr^va^ 
•nvironmertf variable list of the new program 

2. Perform exec system cafl 

3. The new program wiJI recognize this 
tnvtronrnent variable with the he* of Oynf end 
initialize TCEP. 

*. This new TCEP wtl. 

- create debug thread 

- setup TFWP 

- setup exec event In TWJdeve/rt 
-suspend self in step 64 until unless 

continued by the debugger. 



As soon as the child process performs step 57, the blocking while loop in TCED 
established in step 56 above wfl) be broken and a TTJ- VTJ-XEC event data is 
returned to the debugger. This data contains all the information about the child process 
at that stage of this execution. From now on the child process is completely under the 
control of the debugger. 



In step 56, the debugger performs a trace caB 65 and requests TCED to continue the 
10 chBd process, which the TCED services appropriately. 

in step 59, the TCED continues the program. The program is suttfect to the same event 
mask that was set by the debugger on the child process in step 53 above. 



15 Preferred deployment of the Invention 



A preferred deployment of the method and system wiH now be described with reference 
to Figure 5. 

20 In this implementation, the host platform 70 is HP-UX OS running on PA-RISC 

processor and the target platform 71 is HP-UX OS running on 1PF (Itanium) processors 
based on Intel's IA-64 architecture. p 17 
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The debugger 72 used is HPs wdb, which is a gdb-based debugger available on HP- 
UX/PA-RtSC platforms. 

The program 73 is any software compiled with M -g" compiler option on a HP-UX/PA- 
5 RISC platform. 

The software emulator 74 that is used for the implementation of the current invention is 
Aries. Aries is a "dynamic translation"-based software emulator that transparently runs 
all HP-UX/PA-RISC applications on HP-UX/IPF. 

10 It is preferred that the invention is implemented in a UNIX environment, although it will 
be appreciated that the invention may be implemented under any operating system. It 
is preferred that the operating system has similar concepts to the UNIX OS, such as 
the concepts of processes, threads, signals, and system calls. 

1 5 Results of testing the invention 

The invention has been tested using a wdb test-suite that contains about 1 1 ,000 tests 
under above deployment conditions with all the test cases passing. The test cases 
cover almost all facets of wdb commands and wdb-functionality. 

20 

Under this implementation there is a negligible performance hH to the users of wdb. 
Regardless of the introduction of an extra layer of communication in the form of TCE 
Framework, practical observation says that due to the user-inpuMntensive nature of the 
debugger itself, the actual performance degradation is not visible to an extent that it 
25 affects debugging in any manner. 

Additional implementation details 

It is preferred that the operating system supports at least some of the following events: 



Event description 


Unix system ceil that may lead to 
the event generation 


Name of the event genertted 


Process creation 


tefk 


VT_CVT_FORX 


Process termination 


ttft 


rT_EVTEXIT 


Process replacing Itself by another 
process 


exec 


rT_EVT_EXEC 


Thread creation 


Jwp_cnwrte 


rrjevrj.wp_CREA7E 
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Thread termination 


_Jwp__tenwnele 


rr^EVTLWPTr-RMINATE 


Thread exit 


Jwp_e»t 


IT_EVT__LWP^XIT 


Exoepaons 

[on Unix, exceptions generate 
ngnats. otgnais can De powtu oy a 

i mat r\r annMwv nnvorc at mow Ka 

j*ei m Bnouiw proueso rimy ue 
generated during execution by the 


Any excepting operation 
peffQmiM oy a inrvao 


rr_EVT_si<;NAL 


Entry into OS mode 


my system cell 


rrjVTJYSCALL^ENTRY 


Return fawn OS mode 


my system c*U 


IT^EVT.SYSCAiX^RCTl/RN 


Restarted OS seme* (restarted 

iu*tom rail am 1 Imv^ 
iywsni can, on unwj 


my restarted system ceU 


rT_EVT - SYSCALL - RK!JTART 


Aborted 05 service (aborted 
system cell, on Unix) 


Any system call that fa aborted 
by _hwpjaboft_syscallQ system 
Ball 


n_F.VT_ABORT_SYSCALL 


Break-point single step 


my event 


rrjVT^Brr.ssiw 



Specific detail is given below for how an implementation of the invention manages the 
above events: 



Evert description 


Unix system caUthat 
may lead to the event 


TCEP actions 

(entry into TCEP is when D/nT reports the 
corresponding system can entry to TCEP) 


Program creation 
C1TJ-VT_FQRK} 


forte 


1 .in the parent program 

- setup forK event in TfKMtf.. event 

• suspend setf until unless continued by 
debugger. 
Z. In the chid program 

- create debug thread 

- setup 7FWP 

- setup fork event in TMttevsrtf 

- suspend serf until unless continued by 

debugger. 


Program termination 

(TTJEVT_EXIT) 




t . Setup exit event in TMJtf .event 

2. suspend other threads in program 

3. suspend self untt unless 
continued by the debugger. 


program converting aeon vD 
another program 

CTT^EVT.EXEC) 


axec 


1 . Insert s spedal environment vanabte into the 
environment variable 1st of the new program 
I. Perform exec system catt 
3 The new program wtB recognize the 
wTvircnmen! variable with the toip of DynT and 
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ritfafee TCEP. 

4 This new TGEPwill. 

- create debug thread 

- setup TFWP 

- setup exec event in Thdjd.tvmt 

• suspend self until unless continued by 


Thread creation 

(TTLWPCREATE) j 


Jwpjcreats 


1. sets up tfaead creation event in 

TMJd.9v*tt 
I suspend setf until unless continued by the 

debugger* 


Thread termination 
CrT^EVTJLWP TERMINATE) 


JwpJermirBte 


1. sets up thread termination event In 

Thd^id. event 
I. suspends serf una unless continued by the 

debugger. 


Thread exJt 

(rr EVT LWP EXIT) 


Jwpjstt 


1. sets up thread exit event In TMJdsvmtt 
I. suspends self untl unless continued by the 
debugger. 


An aborted system call in a 
thread 

fTT^hVi ABORT_SYSCALL) 


JwpjtortjsyscaH 


1 . sets up thread abort syseafl event to 

2. suspends self until unless continued by the 
debugger. 


Exceptions 

(on Unix, exceptions generate 
signals. Signals can be posted 
by a usar or another program or 
may be generated during 
rwcvtfenbytteOS/ftanftwBre) 
CrrjsrrjUGHAL) 


None 


1. sets up signal event in TMJdeverit 

2. suspends self until unless continued by the 
debugger. 


Entry Into a system cal 

(TT .EVT.SYSCALL^CNTO Y) 


amy System call 


1 . sets up syscaM entry event in 7Tid_W. event 

2. suspends self until unless continued by the 
debugger. 


Return from a system call 

UT.EVT.SYiiCALl^RfcUJRN) 


amy system call 


1 . sets up syseafl return event in TMJtf. event 
2 suspends serf untl untess continued by the 
debugger. 


Restarted system call 
[TTJSVTjRYSCAlXJUeSTART) 


sny restarted system 

call 


1 . seta up tyscaB restart event In Thdjd.ovanr 

2. suspends self until unless continued by the 
debugger. 


3raak-point single step 
[IT_EVT.nPI_SSTEP) 


program Wttfng s 
breakpoint 


1 . sets up breakpoint singfe step event in 
7"hd_taf.evenf 

2. suspends self until unless continued by the 
debugger. 
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Specific details for how the debugger in an implementation of the invention requests 
event data of pending evente in the program is given betow: 







fCEPfrifece 


u aii iii lip| flw 1 


1. Set 7FWO reg=TR4Ce_WW7:' 


NNfe (7FVtftsMa — HK3L«6AO>9 


Wocfcng stoma, until 




<&xKJth*ng>] 


BVWt OCCunf. 








Z. While {TFWDsHus-* 


2. For each TWjtf<to 




EVENT JHXJNO) OR 


begin 






tf(71knttev*rtM0JthOT 






begin 




«hnothing> 


Set rFWP.evw^77xLW.©v*rt 












return to DynT 






and 






and 




EVEWT.ra/NO) then return to 


Set TFVWjtatu&*NO^EVENT_FOUND 




DynT, TRW.evwf 






9tegotottap1. 




[receive* witfi 


1 . Set TFmj^7MC£J#AlT; 




btodonj (Kit ettowed 














EVENT J*Oi)ND) OR 


2. For each fetfjtf <fc> 




{TFWD.status -» 






WJEVENTJVUND) 


rf(TftdJ*ewtfr*0Jthen 






ti n ralr> 

oegn 






Set TFWP,»ywjf- TMJdLevetf 






Set TTOP.l^us^vEWr^OOWD 






return to fl^nf 






end 






■nd 




EVENTJOUNty then return to 






DynT, TFWD.wvf* 






•fee fttUm f» ttttftf found" 






status to DynT (which w* be 






tetommi to debugger by OynT) 
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The invention is capable of supporting a number of tracing calls, including: 



Prggg^nride requests 

- Enable the calling process to be debugged/traced by another process which has 
5 required permissions (TT_PROC_SETTRC) , 

- Attach the debugger to a process already running (TT_PROC_ ATTACH), 

• Detach the debugger from a debugged process (TT_PROC_DETACH), 

• Read from process's data area in memory (TT JPROC_RDD ATA) , 

- Read from process's code/text area in memory (TT_PROC_RDTKXT), 
10 - Write into process's data area in memory (TT_PROC_WRDATA), 

- Write into process's text area in memory (TT_PROC_WRTEXT), 

- Get the process's pathname (TT_PROC_GET_P ATHN AME) 

- Get the process's current process-wide debug event mask 
(TT_PROC_GET_EVENT_MASK), 

15 - Set the process's current program-wide debug event mask 
{TT_PROC_SET_E VENT_MASK) , 

- stop the process (TT_PROC_STOP), 

- Continue the process (TT_PROC_CONTlNUE), 

- Get the page protection bits from the given page belonging to the virtual memory of 
20 the process (TT_PROC_GET_MPRCOXCT), 

- Set the page protection of the given page belonging to the virtual memory of the 
process to the given value {TT_PROC_SET_MPROTECT), 

- Set the system caH bit mask (TT_PROC_SET_SCBM); system call bit mask controls 
the 

25 event reporting of the system call entry and exit events. 

- Force the process to exit (TT_PROC_EXTT), 

- Force the OS to dump the memory and context of the process (TT_PROC_CORE), 



Thread-specific requests 
30 - Stop a thread of the process (TTLWP_STOP), 

- Continue a stopped thread of the process. This request could be accompanied with a 

signal number (on Unix OS) which is to be delivered to the process by the OS as 
soon 

as it starts execution. (TT_LWP_CONTINUE), 
35 - Get the state of the first stopped thread belonging to the process 
(TT_LWP_GET_F1RST_LW?.STATE), 
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- Get the state of the next stopped thread belonging to the process 
(TT_LWP_GET_NEXT_LWPJSTATE), 

- Single-step a thread in the process (TT.LWPSINGLE), 

- Get the thread-wide debug event mask of a thread belonging to the process 
5 (TT_LWP_GET_EVi:NT_MASK). 

- Set the thread-wide debug event mask of a thread belonging to the process 
(TT_LWP_SET_EVENT_MASK), 

- Get the runtime context /state of a thread belonging to the process 
(TT_LWP_GET_STATE). 

10 - Read the register contents of a thread belonging to the process fTT_L WP KUREGS) 

- Write into the of a thread belonging to the process fjT_LW?_WUREGS) 

Specific details on how an enplemertfation of the invention might support the above 
tracing calls are given below: 

15 



TRACE REQUEST 






rrj^OCSKTMC 


VoacOon 


1. Create JuJn 
E.SetupTFW 

t. Return to DynT 


ITJ>ROCJ>K!ACH 


\ . Make trace-caff with request 

2. Set TFWD.t*q = TFVVD.atoto* 

REQJREADY 

3. Return to DynT. 


:WhHe(TFVVD.s«as-" 
ZEQREADY) <donothmg>l 

3. Terminate TOTH 

4. Inform DynT to* program is 
no longer "traced". «0 that 
OynT doeenl pm on tVac*- 
ceff requests to 7"C£P from 
then on* 


njPROCJlDTEXT 




t&QJiBADY) <donothlng>] 


rc_PROC_RDDATA 


1. Make tract-eft* with request 


REQJ&ADY) <donothinff>\ 


rrj'ROCJtfRTEXT 
n.PROC.WRDATA 


i.setTPvyo.mp^gtit3t 
TRrVD. status* REQ_READY 


m*i(TFWD.#dtu3-~ 
REQ_READV) <donatHng>] 

2. For each TMJd, if thread to 
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rRACH REQUEST 



TCCPfeflecO 



RBSPONSEJ&ADY) <donoftmff> 



11. Set TFWD.mq* 

TPWD. statuar REQJ1EADY; end return to 



running state, atop * and set 

7EMFQRAR1LY_STQPPED 
3Set 7FWP.5tefl/s* 

REQ_READY} <donothing>} 



5. Make traoe-ceff with reoyesf 

5. Set TFWD.roq = request TFWD.oetef * 
<eddre*s at wtticn write was performed; 
TFWO.teta2 » «number of bytes written^ Set 

TWhle(THVD.afBfua — 
R£SPONSE_READY) <Ooncttmg> 



\. For edch transition in 
Ccecfte. tf its source address 
fate within the range, 
TBVP.ctafaf, 

TFttP.dafci f + TFWP.dztaZl 
then, remove that translation 
from Ccecfre. 

9. Set TFVVP.stete * 

10. 1 Wife (TFWD.status -= 
REQJEADY) <donothing>] 



12. For each r/lefj* if 
(TTKUAaeele— 

TEMPORARfL Y_STOPPZO), 
then restore it to running state 
and TIMNo^eMe to original 
value 



rr_PROC_GET_PA TllN AK^1 
E 



Make aace-caf with reouesf 



Wo ecaon 



rT_PROC_SKT_EVENT_M 



I.Set TFM&reqp 
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TRACE REQUEST 


TCED(c*us+) 


TCEP 


ASK 


TFWD,dati1=<*\*nt mask p*S39d by 
tfe6ugyef>; TFWD.stotus+REQJEiADY, 

RESPONSEJEADY) <donotttinff> 

4. Set WWfcevefit_iTi3efc*<ewtf /nasfr passed 
by deougger> 

5. Return tpDyn T. 


REQ_READY) <donothtng>] 

2. Set 
a1 

3. Set 

7mP.stefus»RE$PON$E_RE 


ASK 


1 . Return \oDynT, PdttM.mm1t.nm9k (eet by 

SET_EVENT_MASK request) 


Vo dcSon 


nj»ROC_STOP 


1 . Set TFWD.mq*r9quest 
7FWD.&tu9*HEQ„READY 

RESPONSEJ1EADY) <donothing> 
5. Return to DynT 


WMe(TFWD.statu$~* 
9EQJ1ZADY) <donotNng>] 

3. For each TMJd, stop the 
thread if active, end eet 

TDTHJTRACE 

4. Set 

TFWP.*8tos*RESP0NSE_*£ 
ADY 


IT.PROC^CONTTNUE 


1, Set TFWD wrr9qi#$t 
TFW.sNtu&REQJIEADY 

RESPONSE J^EADY} <donoffung> 
5. Return to DynT 


Whfe (TFWD.St3tVS~* 
1EQJEADY) KdonotNngy] 

3. For each TMJd, if ( 
TM^^te<e-S7X?WED^HVl 
7D7H_7HAC£OR 

EJTOJEVENT) then continue 
that (breed 

4. Set 

TFWP.3t9tus*RESP0NSE_RE 
ADY 


rrj.wp_sTOP 


1. Set 7FWD./9Q«/eQu»jt 


Whae(TFWD.stXus~= 
REOJ^ADY) <donothmg>} 
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TRACE REQUEST 


TCED(C9U9*) 


TC£P(ttfctt 




wcMupon>; TFWV.st*tus=REQ_READY; 
lJ*EADY)<<tonothky> 

WhHe (TFWD.st*tu*-= RESPONSE 

5. Return to DynT j 


2. Stop the thread whose id is 
TTW.tfatot, if active. 

3. FortbtTWJd 
corresponding to TFWP.datal 
SetTMJdMate* 

STOPPED JHYJTDTH_TRAC8 

4. Set 

TFW.status=RESPONSEJiE 
4DY 


n_LWPJX)OTINUE 


1. Set TFWD.mpmquast, 

TFWO. deto 1 m <fiuv6d id of the ttvcsd to 6e ecfec 

upon>;TFWO.data2*<tnstruction address at 
which to continue the 

2. White {TFWD.Status RESPONSSJ1EADY) 
<donothing> 

5. Return to DynT 


WKh (TFWDstwtus ~= 

2. FortheTWJd 
corresponding to TFWPctofaf, 
Set niffjttLstirie* 

wor stopped fly tdw 

3. Continue the thrwd whose 
d is 7FWP.date1 

4 Set 

TFWP.status*8ESP0N$E_RE 


nj*OCJjETJIRST_L 

WPSi'ATE 


1. Set TFWD.ie<pii5guwt 

2. While (TFVVD.steft/s RESPONSEJREADY) 
tdonottwxp' 

4. Return to Gynf, TFWD.datal 


WW»efTFWD.3te<us^ 
HEQJtEADY) <donothing>} 

2, Set 

TFWPdataUTMJ&tConttxt 
of (he first stopped thread. 

3. Set 
AO/ 


TT^PROC.GET_NKXTJ, 
WP^STATE 


1 Set TFWD.r&q*requB$z 
TFWD.stetusmRE<l_R£ADY 


ReQ_fl£ADY) <dorwtftwo>] 
2. Set 
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fRACE REQUEST \tOED(c*v99) 


TC£P(eiNctt 




Z White iTFWO.s*tus~= RBSPONSEJ^EADY) 
<donathtng> 

4. Return to DynT t TFWD.&U1 


TFWP.d$t*UThdJd.tContoxi 
of tho next stopped threed 
[TCEP needs to remember the 
fast returned thread). 

3 Set 

TFWP.status=te$PON$E_RE 


IT PROCjGETJMFROTE 
CT 


1 . Make frace-cafl with request 


wacoon 


rT_PROC__SET^MPftOT£C 

r 


1 Make foce-ceU with request 


NO SCOOP 


rT^PROCjSET^SCBM 


1. Set TFWD.nqmrequest 

TFM>.d*a1=<&tm*sk> 

TFVW.statos-REQ_READY; 

2 White (7FWD.*te&/$ -= RESPONSE J1EADY) 
<donothing> 

4. Return to ftwf 


White (TFWD.stntvs -= 
REQJREADY) <donothing>\ 

Z. Set 

Ptifcts.*c6m B »7FWF data! 
3. Set 

TFW.StitUS*RESPONSEJRE 
ADY 


TT.PROCJiXIT 




Noecton 


H'JttOCjCORE 

1 


1 Set TFWOs&r-rwfjest; 
imD.*etuw*RB3j1£ADY 

Z Whle (TFWO.status RESPONSE_READY) 
<donototng> 

Return to OynT 


W^fTPWD.stetfus-* 
R£Q_K£AOy? <dbrwtfwig>J 
<. uer>crMe progrsm core we, 
3. Set 

TFW.status*R£SPONSEJ*Z 
tDY 


IT_LWP_SINGLE 


1. Set TFWD.rvqtfvquest, 

f r KVIJ.CuIia? *-v7I/WK7 fO Or 079 U)fW8Q ID Off SCnSG 

upcn>;TFWD. dat32*<lnstnjction midmss *t 
which to continue the 
tom*>;TFWD.sti^REQJ1EADY 

Z White ~» RESPONSEJ&ADY) 
<~dono&ung> 


WhSe (TFWD.status~= 
REQJREADY) <dotnthiry>] 

2. For the Thdjd 
oomeporKfing to TFWP.d&t&l, 
Set 

ndJdbr*&j*n*rjon*Jnst 



21-08-2003 



13:41 



64 4 4736712 



P. 28 



22 -Aug . 2003 0 : 37 BSW WGTN 64 4.473611,2 



No- 2506 P. 29 



28 HP 200208617 



TRACE REQUEST TC£D (cause) 


TCEP (effect) 




5. Return to DynT. 


ruction^ 
4. Set 

TFWP.statu9=RESPONSE_RE 
ADY 


TTJLWP^ETJEVENTM 
ASK 


1 . Set 7FWD.re<rrw7uest TF WD. datal =<thmad 
fd of the thread to be acted 
upon>;TFWD.dat$2=<nm* event mask to be 
set>; TFWD.status*REq^READY 

2. Set TMJM~tv*rnjrmsk=<event mask 
passed by debugger tor the gnw thread 

White (TFHO.sfefcs — RESPONSE J&ADY) 
<donothing> 

5. Return to DynT 


While (TFWD.status 
REQJ&ADY) <donothrng>] 

2. Set 

ThdJd.9Yent_meek* TFWP.d 
ata2, for the thread whose id is 
TFWP.detai 

3. Set 

TFVMP.5teft«=RESPONSE^R£ 
ADY 


njLWHjGCT^VENTJI 
ASK 


1 Return to DynT, Thdjd.eventjrmk of the 
ponoefnstf thread 


Wo action 


ITJ.WPJiETSTATE 


1. Set TFWD ^request; TFVvV.dataU<thmed 
id of t&e thread to be acted upon>; 
TFWO.atatu&REQJiEADY 

2. White (TBVD.stoft/s — RESPONSE JSCADY) 
«tonothing> 

3. Return to DynT TFWD.cW»2. 


REQLREAOV} «fono0*is>l 
3. Set 

7FWP.data2*ThdJ<LtContaxt 
for the thread whose id is 
TFWP.datal; 

TFW.status=RESPON$E„R£ 

AAV 


tt^ndr jot" \jF\f.\ 


1 . Make tosce<e0 with request 


No action 


njLWPRUREGS 


1 . Map eedh debugger requested register to 
Thd_kLtCont*xt\ user register area in program 

2. Makes tracheal with request 
UJTOOCJtDOATA to read date from the 


Mo action 
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TRACE REQUEST \TCED (cmm) 


TCB>(*ffQCt) 




rantepped program* memory addreee 

(containing u$er registers emulated by Dynl) 
nived at in atop 1 above. 

3. Return this data to Oynf 




rrj.wpjvuREOs 


1 . Map each debugger nwjuwted register to 

Jd. tCorrtaxn user register area in program. 

2. Makes fractal witfi request 
TT_PROC_WRDATA to write data into the 
mapped program* memory addrats (containing 
user registers emulated by Dyn 7) arrived at in 
dap 1 above. 

3. Return to DynT 


No action 



The present invention has the fotowing advantages: 

5 • An application being migrated from platform A to platform B can be debugged in 
the absence of platform A systems, if the debugger of platform A is available. 

• An application being migrated from platform A to platform B can be debugged 
without the need for networking A and B systems in order to run the debugger 

10 remotely from A 

• Programs can be supported on a non-native platform by enabling the 
debugging of that program on the platform when the native platform is no longer 
available. 

15 

• Up until now all components of the development tool-chain, except the 
debugger, from the host platform could be run on the target platform through a 
software emulator. These Include compilers, linkers, etc. With this invention the 
missing link that the execution of the debugger is made possible. Hence using 

20 this invention and pre-existing capabilities of the software emulator, the entire 

tooi-chain of the boat platform can be provided on the target platform. 



• 
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This invention can be used to verify correct emulation by the software emulator 
itself. Utilities, Hke Qdb or tusc. can be used to compare at specific points the 
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state of the debugged or traced program first using the invention within the 
software emulator on the target platform and second on the host platform itself. 
Such comparison is often very useful in locafiefng the area where the software 
emulator may be emulating the program incorrectly. 

5 

While the present invention has been illustrated by the description of the embodiments 
thereof, and white the embodiments have been described in considerable detail, it Is 
not the intention of the applicant to restrict or In any way limit the scope of the 
appended claims to such detail. Additional advantages and modifications will readily 
10 appear to those skffied In the art. Therefore, the invention In its broader aspects is not 
limited to the specific details representative apparatus and method, and fflustrative 
examples shown and described. Accordingly, departures may be made from such 
details without departure from the spirit or scope of applicant 1 * general inventive 
concept. 
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